Currently, 3GPP is considering development of E-UTRA and E-UTRAN as set out in the technical specification 3GPP TS 36.300 v 8.1.0 (2007-06), incorporated herein by way of reference, and related documents. 3GPP Long Term Evolution (LTE) aims to enhance the Universal Mobile Telecommunications System (UMTS) standard, for example, by improving efficiency and services.
In E-UTRAN, user equipment (UE) communicates with a network node, NodeB (eNB), with data being sent on radio bearers (RBs) over a radio link between them. The eNB interfaces with a Mobile Management Entity/System Architecture Evolution Gateway (MME/SAE GW) via an interface designated as S1. An E-UTRAN network includes a plurality of eNBs and MME/SAE GWs.
In LTE, all the Radio Access Network (RAN) functions are integrated in each node, eNB. Downlink user data, that is Internet Protocol (IP) packets, are transmitted from the SAE GW to the eNB. As the UE is handed over from a first, source, eNB to a second, target, eNB, the SAE GW is updated with the second eNB address and the SAE GW starts to send data to that target eNB.
However, to avoid data loss, any data that is already buffered in the source eNB must be forwarded to the target eNB. Also, data that has been sent to the source eNB during the handover (HO) procedure, before the SAE GW is updated with the new eNB address, is also forwarded by the source eNB to the target eNB.
To preserve the order of packets sent to the UE, the target eNB must strive to send data over the radio in the same order as sent by the SAE GW. That is, firstly data buffered by the eNB is sent to the target eNB, followed by data in transit from the SAE GW during the HO process, and only when these have all been sent should the target eNB send to the UE fresh data that it receives directly from the SAE GW.
The message flow for the HO process applied to a UE 1 is shown in FIG. 1 which illustrates a network including a source eNB 2, a target eNB 3 and an MME/SAE GW 4. When the source eNB 2 makes a handover decision based on measurement reports from the UE 1, it sends a Handover Request message to the target eNB 3. At the Admission Control step 5, the target eNB 3 configures the required resources and sends a Handover Request Acknowledge message to the source eNB 2. Following the handover command from the source eNB 2 to the UE 1, the UE 1 detaches from the old cell and synchronises to the new cell associated with the target eNB 3. Also, data packets buffered at the source eNB 2 and any in transit are forwarded to the target eNB 3 over an interface designated X2. Following the handover confirm message at step 10 from the UE 1 to the target eNB 3, a handover completion message is sent to the MME/SAE GW 4 by the target eNB 3. Data packets from the source eNB 2 continue to be delivered to the target eNB 3. The target eNB can then send fresh data arriving over S1 from MME/SAE GW once all the forwarded data from source eNB 2 has been received by it.
Forwarded data from the source eNB to the target eNB may take two forms for LTE: forwarding of data buffered at the source eNB and forwarding of freshly arriving packets at the source eNB over S1. Lossless HO requires that both these types of data are forwarded from the source to the target eNB. 3GPP RAN2 has discussed and agreed the data forwarding principles to provide lossless inter-eNB handover. However, the conditions when lossless HO should be applied have not been discussed so far.
It cannot be assumed that all data received at the source eNB before the HO Command is delivered to the UE is considered “buffered” data and has accordingly been allocated Packet Data Convergence Protocol (PDCP) sequence numbers (SNs). Incoming packets may be provided with a PDCP SN as soon as they are received by the eNB or, alternatively, a PDCP SN may be provided just before delivery to the UE in near real time. Any packets that have not been actually sent to the UE can be treated as fresh data over S1 as long the last used PDCP SN is used correctly.
It was also agreed by 3GPP RAN 2 that forwarding of buffered packets should be carried out based on radio link control (RLC) status reports. RLC status reports are provided where the RLC acknowledged mode (RLC-AM) is selected for a radio bearer. The acknowledged mode (AM) provides enhanced reliability as it allows retransmission of incorrect or lost data packets, and is suitable for non-real time services, for example.
In RLC unacknowledged mode (RLC-UM), no retransmission protocol is used and there are no RLC status reports, and thus data forwarding is not envisaged for RLC-UM. The unacknowledged mode may be used, for example, for certain radio resource control (RRC) signalling and voice over IP (VoIP). The choice as to which RLC mode to adopt is based on the residual bit error rate (BER) required for the bearer and the Hybrid Automatic Repeat Request (HARQ) operating point.